home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0468.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.6 KB  |  87 lines
  1. Dan Connolly writes:
  2. > Good point. I didn't mean that we should make the physical distance
  3. > to the link destination known to the user. But I think users would
  4. > benefit from knowledge about the logical distance -- i.e. is
  5. > it part of the same node, part of the same document, or in some
  6. > other work completely? Is it more specific or more general
  7. > than this node?
  8.  
  9. Maybe a compromise: if linking to a point in the same document, color
  10. the anchor orange; if linking to a point on the same server, color it
  11. red; if linking to somewhere else entirely, color it violet.  Or a
  12. variation on that theme.  This wouldn't require changing HTML and
  13. wouldn't be too obtrusive to those of us who like transparency.
  14.  
  15. > [Discussion on what to do with links to GIF files.]  So perhaps it's
  16. > not the HTML data format that's doomed, but the <A> element. I guess
  17. > the lesson is: you can't teach an old element new tricks.
  18.  
  19. I think looking at the file extension will solve 95% of the cases
  20. (that's what extensions are for, after all).  The remaining 5% could
  21. be addressed by Content-Type.  The browsers should be brought up to
  22. speed.  That's one approach -- just getting multimedia out the door
  23. and merged into the current HTML spec calls for the simplest solution
  24. possible, at the moment.
  25.  
  26. > Counterpoint: when the design is complete, performance-critical code
  27. > can always be written in C and added as a module. In the mean time,
  28. > the benefits of rapid-prototyping outweigh the performance
  29. > penalties.
  30.  
  31. Yeah but, yeah but, once something is written with rapid prototyping
  32. in mind and turns out to work, odds are it's going to be *the*
  33. implementation, as its implementor goes on to bigger and better
  34. things.
  35.  
  36. > I don't mean to base the W3 architecture on Python -- only some
  37. > implementations.
  38.  
  39. Right.  Those implementations then will be (no offense to the Python
  40. folks intended, but here it comes...) chained to Python, which will
  41. put an instant damper on their general usefulness -- they're never
  42. gonna be merged into anything else and thus made more useful, unless
  43. that something else uses Python also, which (as is the case with all
  44. the rest of these systems) is just plain doubtful.
  45.  
  46. > Viola and tk/tcl: These try to do what's already been done in
  47. > the Xaw and Motif toolkits, and they don't do it as well. (I suppose
  48. > this is your point...)
  49.  
  50. Yup.
  51.  
  52. > Midas: This is a specially designed language highly suited to it's
  53. > purpose. Only the highest level of code in the Midaswww browser is
  54. > written in Midas. All the rest is reusable. Tony did a heck of a
  55. > job.
  56.  
  57. I agree with the latter point, but not the former.  There's very
  58. little reusable code in Midaswww.  I spent quite a bit of time trying
  59. to rip the SGML widget out and use it separately, and it's just not
  60. possible with the current Midaswww architecture.
  61.  
  62. > VUIT: how did this get in there?
  63.  
  64. It (or something similar) is being used to generate UIL code for
  65. Midaswww, which counts as another toolkit in my book, since I can't
  66. effectively edit it by hand -- despite the fact I know Motif a lot
  67. better than I'd like to, very little of my existing knowledge carries
  68. over.
  69.  
  70. > NeXT: I'd drop X/Xt/Xaw for NextStep in a second if it was an
  71. > option. NextStep isn't free, so it hasn't proliferated like X.
  72. > That's pretty much the end of the story.
  73.  
  74. Agreed on all counts.  Again, my point.
  75.  
  76. I'm not arguing *against* special toolkits and builders in the
  77. abstract -- I think they're great, for the lone programmer.  But it's
  78. just plain a fact that there's nothing standardized about them;
  79. they're not available on most systems; they're not going to make code
  80. reusability practically possible, and their use causes too much
  81. reinventing of the wheel.
  82.  
  83. Cheers,
  84. Marc
  85.  
  86.  
  87.